Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Passing parameters

The publisher can pass parameters in the same way as for a RUN statement. Ordinarily, any such parameters are INPUT parameters so that the publishing procedure can pass one or more values into each subscriber. INPUT parameters are the norm because the publisher normally does not want to know the specifics of who the subscribers are and therefore is unlikely to be interested in output from them. If the publisher wants to get a specific response back, then it is better to use a RUN statement with a known procedure handle to run it in.

In particular, an OUTPUT parameter is almost always a bad idea because its value is received only from the last subscribing procedure to execute. If there are multiple subscribers, the OUTPUT parameter returned by the rest of them is discarded. Since there is no way to determine which of multiple subscribers will run last, this is not a reliable or useful mechanism.

On the other hand, there are times when it can be useful to pass an INPUT-OUTPUT parameter. In this case, each subscriber in turn receives the current value of the parameter and can act on it and modify it. The next subscriber receives the modified value and can modify it further. Finally, the publisher receives it as output from the final subscriber and can see the collective result. This is useful in cases where all the subscribers need to contribute something to a final total, perhaps adding a value to the current value of the parameter or appending something to the end of a delimited list. The publisher then sees the result of all the calls. Again, there is no determined order for the subscribers to be called, but if the order of execution is not important, then an INPUT-OUTPUT parameter is sometimes useful.

The final subscriber can also pass back a string in a RETURN statement that is received by the publisher as the RETURN-VALUE just as if the publisher had used a RUN statement. Again, there is no way to know which subscriber will be the final one called, so each subscriber could append text to the existing RETURN-VALUE in a way similar to using an INPUT-OUTPUT parameter in a form such as the one in the following example. In this code, the RETURN statement appends the value of the local CHARACTER variable cMyIdent to the current RETURN-VALUE:

RETURN RETURN-VALUE + “ “ + cMyIdent.

Each subscriber can see the value returned by the previous subscriber in its RETURN-VALUE. If this is the final statement in each subscriber’s internal procedure, then the publisher can look at the value of RETURN-VALUE and see all the accumulated values of cMyIdent for all the subscribers.

The PUBLISH statement always executes NO-ERROR. If there are no subscribers, no error message results. If one or more subscribers have a parameter list that does not match the parameters in the PUBLISH statement, then those subscribers do not receive the event and, likewise, no error results. For this reason, it is important to make sure that subscribers have the proper calling sequence. Otherwise, their procedures will not be run and it might not be clear to you why the PUBLISH statement seems to have failed.